The teemss2 projects has quite a complex deployment requirement.

1. Using the hardware from each vendor requires a different set of jar files.
2. We don't want teachers having to download jars they don't need.
3. Each school needs a different download point so we give them only their school student information and no more.

h3 School Download Point
Working backwards we start with the school download point. This is a jnlp file that will sit in the cache of the computers at the school. I could also be saved to their desktop.
It needs:

• a reference to a starting otml file for the school. This otml file will pulls in:
  • student, teacher, and class information so they can log in.
  • vendor specific technical hint settings.
  • vendor specific device setting
• all the jar files needed. This include the vendor specific device jars.

Jar Options

The otml part is one issue and the jars are another. For handling the jars we could:

1. static jnlp for each school that contains:
   1. all the jars and the currently released version for all the jars.
   2. a reference to the jars located in a versioned extension
      1. this is untested
      2. it requires a dummy jar in the main jnlp to call the main class in the extension
      3. the safest way is to have one extension jnlp for each vendor, but this isn't much different
         from option 1.2. It means that several jnlp files need to be generated for each release
      4. it is safe to test
2. dynamic jnlp for each school that contains:
   1. a filtered import of the resources for that vendor. The import would be filtered based on the vendor. In this case the jar deployment code just needs to generate an appropriate master version file. Then the dynamic import code can create the jnlp using its filters. I'm thinking now of using xslt and cocoon for doing this.
      The trick with that is using a technology that Ann can use to setup the reference to the otml file correctly.